課程：RN 跨平台開發基礎 第 2 堂：核心元件與工具鏈
Expo vs RN CLI
在我們深入研究了 React Native 的核心元件後，你可能會產生一個疑問：既然 React Native 的本質是將 JavaScript 邏輯轉譯為原生 UI，那為什麼我們在開發時，有的時候需要打開 Xcode 或 Android Studio 去調整設定，有的時候卻只需要改改 app.json 就能完成上架？
這就涉及到了 React Native 開發中最重要的「工具鏈」選擇。想像一下，如果你要蓋一棟房子，你是要從買地、請建築師、找水電工、自己去跑建管處執照開始（React Native CLI），還是買一間已經建好主體結構，並由建商提供管線維護與公共設施服務，你只需要專心裝潢室內的「精裝房」（Expo）？
這兩種路徑決定了你與「原生層」打交道的方式，也直接影響了你 debug 的難易度與開發效率。
核心概念：封裝 vs 裸露
在 React Native 的世界裡，開發環境主要分為兩大派系：React Native CLI（通常被稱為社區版或核心版）以及 Expo。
React Native CLI：只有引擎與底盤
當你使用 npx react-native init 建立專案時，你得到的是最純粹的 React Native 結構。這就像是你買了一具強大的引擎與底盤，但剩下的所有東西——從空調系統到導航螢幕——你都得自己裝上去。
在這種模式下，你的專案目錄裡會清晰地看到 ios 和 android 兩個資料夾。這不是裝飾品，它們是完整的 Xcode 專案與 Android Studio 專案。如果你想加入一個「手機震動」的功能，你可能需要手動修改 iOS 的 Info.plist 或是 Android 的 AndroidManifest.xml。這種「裸露」的狀態給了你極大的自由，但也意味著你需要具備一定的原生開發知識，當 Gradle 版本衝突或 CocoaPods 安裝失敗時，你必須親自下場維修。
Expo：全配備的豪華轎車
Expo 並不是 React Native 的「替代品」，而是在 React Native 之上疊加的一層強大封裝（Encapsulation）。它誕生的初衷是為了讓 Web 開發者能像寫網頁一樣寫 APP，而不需要碰觸到那些讓人頭痛的原生組態。
Expo 幫你抽象掉了 90% 的原生配置。你不需要安裝 Xcode（除非你要跑模擬器），你不需要管理複雜的證書，你甚至不需要在那兩個龐大的原生資料夾裡尋找設定。它提供了一套標準化的 API，讓你能用統一的 JavaScript 語法去呼叫相機、定位、感測器等功能。
深入拆解工具鏈的演進
隨著技術的發展，Expo 的角色已經從一個「給初學者的玩具」轉變成了「專業開發的首選框架」。要理解這一點，我們必須拆解它的工作流程。
Managed Workflow：無痛的黑盒子
這是大多數人對 Expo 的第一印象。在 Managed Workflow 中，你完全不需要管 ios 和 android 資料夾（它們甚至不會出現在你的目錄中）。所有的原生程式碼都由 Expo 在雲端幫你管理與編譯。
- 優點：極速上手，環境單純。你只需要專注於編寫 JS 程式碼。
- 缺點：如果你需要使用一個非常冷門、Expo 沒封裝進去的原生套件，你就會撞到牆。在早期，這意味著你必須「Eject」（彈出），而這通常是一個不可逆且痛苦的過程。
Bare Workflow 與現代的開發模式
為了縮小靈活性與便利性之間的鴻溝，Expo 演進出了 Bare Workflow（現在更多被稱為使用了 Expo Modules 的開發模式）。這是一個「我全都要」的方案。
你保留了對 ios 和 android 資料夾的控制權（你可以自由修改原生代碼），但你依然可以使用 Expo 提供的強大模組化工具。這讓開發者可以在保持高度客製化的同時，享受 Expo 帶來的開發便利。
Expo Go vs Development Builds
這是許多開發者最容易搞混的地方，也是理解「原生能力邊界」的關鍵。
- Expo Go：這是一個你在 App Store 或 Google Play 下載的 APP。它就像是一個「萬用容器」。當你在電腦上寫 JS 程式碼時，Expo Go 會下載你的 JS Bundle 並執行它。
- 預測一下：如果你在專案裡加入了一個需要修改原生程式碼的套件（例如一個特殊的藍牙驅動），Expo Go 能跑嗎？
- 答案是：不能。 因為 Expo Go 的原生環境是固定的。它內建了常用的相機、定位等功能，但它無法預知你未來想加什麼奇怪的原生功能。
- Development Builds (Dev Client)：這是現代開發的最佳實踐。你可以把它想像成一個「為你量身打造的專屬版 Expo Go」。
- 當你需要加入自定義的原生代碼時，你會編譯出一個專屬於你專案的測試 APP（Dev Build）。這個 APP 包含了你所有需要的新零件，同時依然保有像 Expo Go 那樣可以即時重新載入（Fast Refresh）的開發體驗。
權衡與選擇：為什麼 Expo 逐漸成為主流？
對於你已經上架的兩款 APP，如果你是使用 Expo 開發的，你可能已經享受過它的好處；如果你是使用 CLI，你或許曾為了處理推送通知（Push Notification）的證書而煩惱不已。
EAS (Expo Application Services)：雲端的神隊友
EAS 是 Expo 近年來最強大的殺手鐧。它將 APP 的**打包（Build）與提交（Submit）**雲端化了。
- 免除硬體限制：以前要打包 iOS APP，你必須擁有一台 Mac。現在，透過 EAS Build，你可以在 Windows 電腦上下指令，讓 Expo 的雲端伺服器幫你跑 Xcode 編譯。
- 自動化流程：它幫你處理了最折磨人的 Apple 證書管理（Code Signing），這對獨立開發者來說簡直是救命稻草。
OTA (Over-The-Air) 更新：繞過審核的法寶
這是 RN 開發中最迷人的特性之一。回想一下我們學過的渲染機制：JS 邏輯與原生層是分離的。
- 如果你只是改了幾行 JavaScript（例如修正一個文字錯字或調整顏色），你可以透過 OTA 更新（如 Expo Updates）直接將新的 JS Bundle 推送到使用者的手機上。
- 使用者下次打開 APP 時，就會自動載入新版。不需要重新提交給 App Store 審核，也不需要使用者去商店更新。
- 注意邊界：如果你修改了原生代碼（例如新增了一個需要權限的套件），OTA 就不管用了，你必須重新提交二進位檔案（ipa/apk）到商店。
什麼時候該選擇 React Native CLI？
雖然 Expo 現在非常強大，但在以下情境，CLI 依然有其必要性：
- 極端包體優化：Expo 為了方便，預設會封裝很多你可能用不到的模組，這會讓基礎包體較大（雖然現在已有改進）。如果你的 APP 對幾 MB 的大小斤斤計較，CLI 更適合。
- 深度原生客製：如果你正在開發一個需要深度修改 Android 系統底層行為，或是開發一個與特定硬體設備（如專業醫療儀器）高度整合的 APP，繞過 Expo 的封裝直接與原生層對話會更直覺。
- 遺留專案維護：很多大型企業的專案是在 Expo 還不成熟時建立的，遷移成本極高。
你的 APP 處於哪個位置？
身為已經有兩款 APP 上架經驗的開發者，回想一下你過去遇到的問題：
- 當你想加入「背景音樂播放」時，你是直接安裝一個套件就能動，還是要在
AppDelegate.m裡寫一堆 Objective-C？ - 當你要上架 Android 版時，你有沒有為了設定
keystore或是處理 64-bit 支援而卡關？
目前 React Native 官方（特別是在 New Architecture 推出後）已經明確推薦新專案優先使用 Expo。這不是因為 CLI 不好，而是因為 Expo 已經把「如何把 JS 變成原生 APP」這件事的維護成本降低到了極點。
理解了這層關係，你在看到 AI 生成的程式碼時就能更有感。如果看到程式碼裡出現 expo- 開頭的套件，你就知道這是一個經過 Expo 封裝、跨平台一致性較好的模組；如果看到需要你手動去 ios/ 資料夾下修改檔案的教學，你就知道你正在觸碰「原生邊界」。
總結與銜接
在本章節中，我們釐清了開發工具鏈的本質差異。React Native CLI 提供了「裸露」的控制權，適合追求極致靈活性的專業場景；而 Expo 則透過強大的「封裝」與雲端服務（EAS），極大地提升了開發效率與跨平台的一致性。
工具鏈的選擇決定了你如何建構 APP，但無論你選擇哪一種，最終呈現在使用者面前的都是 UI。而要把 UI 畫得漂亮、排得整齊，我們就必須掌握 React Native 的樣式系統。
在下一個主題 Topic 2：元件系統與樣式 中，我們將從底層原理出發，探討為什麼 React Native 的樣式雖然長得像 CSS，但骨子裡卻完全不同。我們會拆解 StyleSheet.create 的效能優化原理，並深入研究 RN Flexbox 那五個與網頁版完全不同的關鍵預設行為。準備好進入樣式的世界了嗎？這才是讓你的 APP 從「能跑」進階到「有質感」的關鍵一步。